Extracting Build Changes with BUILDDIFF

Build systems are an essential part of modern software engineering projects. As software projects change continuously, it is crucial to understand how the build system changes because neglecting its maintenance can lead to expensive build breakage. Recent studies have investigated the (co-)evolution of build configurations and reasons for build breakage, but they did this only on a coarse grained level. In this paper, we present BUILDDIFF, an approach to extract detailed build changes from MAVEN build files and classify them into 95 change types. In a manual evaluation of 400 build changing commits, we show that BUILDDIFF can extract and classify build changes with an average precision and recall of 0.96 and 0.98, respectively. We then present two studies using the build changes extracted from 30 open source Java projects to study the frequency and time of build changes. The results show that the top 10 most frequent change types account for 73% of the build changes. Among them, changes to version numbers and changes to dependencies of the projects occur most frequently. Furthermore, our results show that build changes occur frequently around releases. With these results, we provide the basis for further research, such as for analyzing the (co-)evolution of build files with other artifacts or improving effort estimation approaches. Furthermore, our detailed change information enables improvements of refactoring approaches for build configurations and improvements of models to identify error-prone build files.Comment: Accepted at the International Conference of Mining Software Repositories (MSR), 201

Structure of the Golgi and Distribution of Reporter Molecules at 20°C Reveals the Complexity of the Exit Compartments

Incubating cells at 20°C blocks transport out of the Golgi complex and amplifies the exit compartments. We have used the 20°C block, followed by EM tomography and serial section reconstruction, to study the structure of Golgi exit sites in NRK cells. The dominant feature of Golgi structure in temperature-blocked cells is the presence of large bulging domains on the three trans-most cisternae. These domains extend laterally from the stack and are continuous with “cisternal” domains that maintain normal thickness and alignment with the other stacked Golgi cisternae. The bulging domains do not resemble the perpendicularly extending tubules associated with the trans-cisternae of control cells. Such tubules are completely absent in temperature-blocked cells. The three cisternae with bulging domains can be identified as trans by their association with specialized ER and the presence of clathrin-coated buds on the trans-most cisterna only. Immunogold labeling and immunoblots show a significant degradation of a medial- and a trans-Golgi marker with no evidence for their redistribution within the Golgi or to other organelles. These data suggest that exit from the Golgi occurs directly from three trans-cisternae and that specialized ER plays a significant role in trans-Golgi function

Do code review practices impact design quality? a case study of the qt, vtk, and itk projects

Abstract-Code review is the process of having other team members examine changes to a software system in order to evaluate its technical content and quality. A lightweight variant of this practice, often referred to as Modern Code Review (MCR), is widely adopted by software organizations today. Previous studies have established a relation between the practice of code review and the occurrence of post-release bugs. While the prior work studies the impact of code review practices on software release quality, it is still unclear what impact code review practices have on software design quality. Therefore, using the occurrence of 7 different types of anti-patterns (i.e., poor solutions to design and implementation problems) as a proxy for software design quality, we set out to investigate the relationship between code review practices and software design quality. Through a case study of the Qt, VTK and ITK open source projects, we find that software components with low review coverage or low review participation are often more prone to the occurrence of anti-patterns than those components with more active code review practices

Repeated Builds During Code Review: An Empirical Study of the OpenStack Community

Code review is a popular practice where developers critique each others' changes. Since automated builds can identify low-level issues (e.g., syntactic errors, regression bugs), it is not uncommon for software organizations to incorporate automated builds in the code review process. In such code review deployment scenarios, submitted change sets must be approved for integration by both peer code reviewers and automated build bots. Since automated builds may produce an unreliable signal of the status of a change set (e.g., due to ``flaky'' or non-deterministic execution behaviour), code review tools, such as Gerrit, allow developers to request a ``recheck'', which repeats the build process without updating the change set. We conjecture that an unconstrained recheck command will waste time and resources if it is not applied judiciously. To explore how the recheck command is applied in a practical setting, in this paper, we conduct an empirical study of 66,932 code reviews from the OpenStack community. We quantitatively analyze (i) how often build failures are rechecked; (ii) the extent to which invoking recheck changes build failure outcomes; and (iii) how much waste is generated by invoking recheck. We observe that (i) 55% of code reviews invoke the recheck command after a failing build is reported; (ii) invoking the recheck command only changes the outcome of a failing build in 42% of the cases; and (iii) invoking the recheck command increases review waiting time by an average of 2,200% and equates to 187.4 compute years of waste -- enough compute resources to compete with the oldest land living animal on earth.Comment: conferenc

Establishment of Epstein-Barr Virus Growth-transformed Lymphoblastoid Cell Lines

Infection of B cells with Epstein-Barr virus (EBV) leads to proliferation and subsequent immortalization, resulting in establishment of lymphoblastoid cell lines (LCL) in vitro. Since LCL are latently infected with EBV, they provide a model system to investigate EBV latency and virus-driven B cell proliferation and tumorigenesis1. LCL have been used to present antigens in a variety of immunologic assays2, 3. In addition, LCL can be used to generate human monoclonal antibodies4, 5 and provide a potentially unlimited source when access to primary biologic materials is limited6, 7

Verifying head impacts recorded by a wearable sensor using video footage in rugby league: A preliminary study

Background: Rugby league is a full-contact collision sport with an inherent risk of concussion. Wearable instrumented technology was used to observe and characterize the level of exposure to head impacts during game play. Purpose: To verify the impacts recorded by the x-patch™ with video analysis. Study design: Observational case series. Methods: The x-patch™ was used on eight men’s semi-professional rugby league players during the 2016 Newcastle Rugby League competition (five forwards and three backs). Game day footage was recorded by a trained videographer using a single camera located at the highest midfield location to verify the impact recorded by the x-patch™. Videographic and accelerometer data were time synchronized. Results: The x-patch™ sensors recorded a total of 779 impacts ≥ 20 g during the games, of which 732 (94.0%) were verified on video. In addition, 817 impacts were identified on video that did not record an impact on the sensors. The number of video-verified impacts ≥ 20 g, per playing hour, was 7.8 for forwards and 4.8 for backs (range = 3.9–19.0). Impacts resulting in a diagnosed concussion had much greater peak linear acceleration (M = 76.1 g, SD = 17.0) than impacts that did not result in a concussion (M = 34.2g, SD = 18.0; Cohen’s d = 2.4). Conclusions: The vast majority (94%) of impacts ≥ 20 g captured by the x-patch™ sensor were video verified in semi-professional rugby league games. The use of a secondary source of information to verify impact events recorded by wearable sensors is beneficial in clarifying game events and exposure levels

An Empirical Study of Goto in C Code from GitHub Repositories

ABSTRACT It is nearly 50 years since Dijkstra argued that goto obscures the flow of control in program execution and urged programmers to abandon the goto statement. While past research has shown that goto is still in use, little is known about whether goto is used in the unrestricted manner that Dijkstra feared, and if it is 'harmful' enough to be a part of a post-release bug. We, therefore, conduct a two part empirical study -(1) qualitatively analyze a statistically representative sample of 384 files from a population of almost 250K C programming language files collected from over 11K GitHub repositories and find that developers use goto in C files for error handling (80.21±5%) and cleaning up resources at the end of a procedure (40.36 ± 5%); an